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FOREWORD 


The  management  of  technical  requirements  which  define  systems,  system 
equipment,  or  individual  equipments  and  changes  thereto  is  termed  "Configura¬ 
tion  Management."  Within  the  Electronic  Systems  Division  (ESD),  the  Staff 
Office  specifically  charged  with  the  responsibility  for  implementation  of 
Configuration  Management  and  AFSCM  375-1  is  the  Technical  Requirements  and 
Standards  Office  (EST).  Effective  utilization  of  the  Configuration  Manage¬ 
ment  Manual  has  required  development  of  supplemental  policy  and  guidance  at 
ESD.  This  report  is  a  result  of  experiences  derived  from  application  of 
AFSCM  375-1;  Configuration  Management  During  Definition  and  Acquisition 
Phases,  dated  1  June  1964,  on  programs  assigned  to  ESD. 


REVIEW  AND  APPROVAL 


This  Technical  Report  has  been  reviewed  and  is  approved. 


USAF 
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ABSTRACT 


Application  of  Configuration  Management  Exhibits  on  ESD  Programs  has 
indicated  that  the  terminology  contained  within  them  can  be  subject  to 
interpretation.  This  report  identifies  problem  areas  that  required  clarifica¬ 
tion  and  workable  approaches  taken  that  were  considered  to  be  in  accordance 
with  the  intent  of  AFSCM  375-1* 
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SECTION  I 


INTRODUCTION 


Configuration  Management  is  defined  as  the  management  of  technical  require¬ 
ments  which  define  systems,  system  equipment,  or  individual  equipment  and 
changes  thereto.  It  is  implemented  through  procedures  by  which  uniform  and 
mutually  supporting  methods  for  configuration  identification,  control,  and 
accounting  are  established  and  maintained  for  systems  and  equipment  and  for 
components  of  systems  and  equipment.  AFSCM  375-1*  Configuration  Management 
During  Definition  and  Acquisition  Phases,  establishes  the  technique  of  base¬ 
line  management.  Three  baselines  which  serve  as  engineering  reference  points, 
i.e..  Program  Requirements,  Design  Requirements,  and  Product  Configuration 
Baselines,  are  defined  in  terms  of  specification  formats. 


The  relationship  between  Configuration  Management  requirements  for  uniform 
specifications,  identification,  control,  and  accounting,  and  the  various 
exhibits  of  APSCM  375-1  is  as  follows: 

Requirements  Exhibit(s)  Application 

Uniform  Specifications  I,  II,  III,  IV,  V,  VI 


Configuration  Control 


VIII,  VII,  IX 


Configuration  Identification 


X,  XI,  XII,  XIII 


Reviews,  Inspections,  Demonstrations  XIV 


Configuration  Accounting 


XV,  XVI,  XVII,  XVIII 


Application  of  the  above  Configuration  Management  Exhibits  on  ESD 
Programs  has  revealed  some  difficulties  in  their  interpretation.  Succeeding 
sections  of  this  report  indicate  problems  encountered  and  the  policy  and 
guidance  offered  which  was  considered  to  be  workable  and  in  accordance  with 
the  intent  of  APSCM  375-1* 


SECTION  II 


SYSTEM  SPECIFICATION 


The  present  AFSCM  375-1  concept  of  uniform  specifications  creates  diffi¬ 
culties  in  application  of  Exhibit  I  on  those  ESD  Systems  which  are  incremental 
and  evolutionary  in  nature.  Two  problems  exist.  The  first  problem  concerns 
system  elements  and  the  second  problem  concerns  system  segments.  Regarding 
system  elements,  the  situation  arises  where  several  major  integrated  portions 
of  a  system  with  unique  performance  requirements  exist  but  which  are  never 
contracted  for  as  a  separate  entity  (e.g.,  Joint  Task  Force/joint  Operating 
Center).  Therefore,  these  system  elements  cannot  be  considered  as  segments 
under  the  present  AFSCM  375-1  concept.  Yet  a  means  for  documentation  tracea¬ 
bility  is  required.  Regarding  the  second  problem,  it  is  often  desirable  to 
contract  on  a  system  segment  basis  without  placing  the  entire  system  specifica¬ 
tion  on  contract.  There  are  several  reasons  for  this,  among  which  are: 

a.  It  is  not  always  desirable  to  reveal  the  total  scope  of  the  task 
to  a  system  segment  contractor. 

b.  System  analysis  requirements  are  continuously  performed  and  the 
system  specification  for  evolutionary  systems  changes  with  continual  addition 
of  incremental  segments. 

The  present  AFSCM  375-1  manual  does  not  provide  a  vehicle  with  which  to 
contract  on  a  segment  basis  as  segments  become  identified  without  placing 
the  entire  system  specification  on  contract. 

In  order  to  alleviate  these  two  problems  and  comply  with  the  intent  of 
AFSCM  375-1;  the  following  concept  was  developed: 

a.  Structure  the  system  specification  into  volumes.  One  volume  to 
contain  overall  system  requirements  and  other  separate  volumes  corresponding 
to  each  system  element.  System  elements  to  be  listed  in  Volume  1  of  the 
General  System  Specification. 

b.  Volume  2,  etc.,  to  also  be  prepared  to  the  format  of  AFSCM  375-l> 
Exhibit  I,  but  to  reflect  system  element  unique  requirements  and  indicate 
the  segments  of  the  system  element. 

c.  The  cover  sheet  for  system  elements  to  be  as  follows: 

Performance  and  Design  Requirements  For  The 
XXXX  System 

Volume  2 

XXXX  System  Element 
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d.  Preparation  of  segment  specifications  in  accordance  with  AFSCM 
375-1,  Exhibit  I,  to  be  used  for  contracting  purposes.  End  items  peculiar 
to  the  segment  to  be  listed  in  the  segment  specification.  The  title  page  of 
the  segment  specification  to  read: 

Performance  and  Design  Requirements  For  The 
(Name  Segment)  Name  System 

e.  Preparation  of  contract  end  item  (CEl)  specifications  in  lieu  of 
segment  specifications  in  those  instances  where  contracting  is  on  an  end 
item  basis.  Such  end  items  to  be  listed  as  segments  of  the  system  element 
to  which  they  pertain. 

A  need  often  exists  to  demonstrate  that  the  performance  level  of  a  system  is 
equivalent  to  the  performance  of  the  same  or  similar  systems  established  by 
the  Category  II  test  program,  without  the  extensive  expenditures  of  resources 
required  of  the  original  Category  II  test  effort.  This  testing  may  result 
from  reprocurement  and  installation  of  a  similar  system  (which  might  be 
furnished  as  AGE  to  another  system),  the  spatial  relocation  of  the  original 
system  (for  test  or  logistic  purposes),  or  in  a  multiple  fixed  site  procure¬ 
ment  wherein  the  Category  II  "system"  test  configuration  requires  only  one 
or  more  of  these  independent  sites,  with  deployment  and  activation  of  the 
remaining  sites.  Although  it  is  still  necessary  to  insure  compliance  with 
the  system  specification  performance  requirements,  it  is  not  economically 
justifiable  to  repeat  the  entire  Category  II  test  effort  in  these  cases.  An 
approximate  parallel  can  be  drawn  at  the  CEI  level  between  the  relative 
complexity  of  the  test  effort  required  to  comply  with  Section  4  of  the  Part 
I  Specification  (i.e.,  qualification)  and  Section  4  of  the  Part  II  Specifica¬ 
tion  (i.e.,  acceptance).  The  same  level  of  effort  should  be  obtained  at 
the  system  level  between  system  Category  II  and  system  acceptance  tests. 

This  situation  can  be  alleviated  by  including  in  Section  4  of  Exhibit  I 
provision  for  establishing  demonstration/acceptance  requirements  at  a  system 
level.  These  measures  would  be  identified  during  Contract  Definition  and 
verified  during  the  normal  Category  II  development  test  program  for  subse¬ 
quent  use.  They  would  comprise  the  minimum  tests  necessary  to  demonstrate 
acceptable  system  performance  in  the  most  economical  and  expeditious  manner 
and  at  the  grossest  level  feasible,  i.e.,  one  test  which  might  demonstrate 
several  requirements  or  a  "quick"  test  which  would  yield  the  approximate 
results  of  an  elaborate  Category  II  test.  The  following  new  section  can  be 
included  in  Exhibit  I: 

Section  4-3,  System  Technical  Demonstration/Acceptance  Tests.  This 
section  shall  specify  the  minimum  system  demonstration/acceptance  test 
requirements  which  verify  that  a  system  which  is  essentially  configured  like 
the  Category  II  system  tested  can  perform  to  an  equivalent  performance  level 
verified  during  Category  II,  without  (necessarily)  repeating  all  of  the 
Category  II  tests  in  kind,  number,  or  scope.  Generally,  the  test  requirements 
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will  be  selected  from  Sections  3*1*1  and  3*1*3  during  Contract  Definition 
and  the  method  of  verification  will  be  subsequently  validated  during  the 
development  test  program,  to  the  satisfaction  of  the  procuring  agency. 

NOTE:  The  procuring  activity  reserves  the  right  to  require 

contractual  compliance  with  any  or  all  performance 
requirements  included  in  Sections  3*1*1  and  3*1*3  if 
it  deems  necessary  or  desirable. 

Requirements  specified  herein  shall  be  specified  to  the  level  of  detail  which: 

a.  Permits  ready  identification  of  each  selected  verification 
requirement  in  Section  4.3  with  the  selected  performance  requirement  in 
Section  3* 


b.  Specifies  a  verification  requirement  and  method  or  alternate 
method  to  that  specified  in  Section  4.2  for  verifying  the  associated  perform¬ 
ance  requirement  in  Sections  3*1*1  and  3*1*3*  Methods  of  verification  may 
include  demonstrations,  test,  and  evaluation  of  test  data. 

c.  Specifies  each  requirement  for  verification  to  the  level  of 
detail  necessary  to  establish  the  scope  and  accuracy  of  the  test  method. 

AFSCM  375-1  presently  anticipates  that  the  System  Program  Office  (SPO), 
possibly  with  the  help  of  a  not-for-profit  organization,  will  prepare  Sections 
3*1  and  3*2  of  the  system  specification  during  Phase  1A,  and  industrial 
contractors  will  prepare  Section  3*3  during  Phase  IB.  Consideration  should 
be  given  to  requiring  that  the  Using  Command,  rather  than  the  SPO,  prepare 
at  least  selected  portions  of  Section  3*1  during  or  before  Phase  1A.  It  is 
also  advantageous  to  have  other  commands  such  as  AFLC  and  ATC  prepare  those 
sections  of  the  system  specification  that  apply  directly  to  them.  Further¬ 
more,  Exhibit  I  does  not  provide  adequate  coverage  of  intersystem  interface 
requirements.  Subparagraphs  are  allocated  in  Section  3*3  to  cover  intra¬ 
system  interfaces,  but  this  was  not  considered  to  be  an  appropriate  place  to 
discuss  performance  requirements  involving  the  interactions  between  several 
separate  systems.  This  problem  was  solved  for  the  BUIC  III  System  Specifica¬ 
tion  by  adding  a  new  Section  3* 1*1*4,  to  present  functional  and  technical 
interface  requirements  between  BUIC  III  and  some  20-odd  other  systems. 
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SECTION  III 


CONTRACT  END  ITEM  SPECIFICATIONS 


Some  problems  in  interpretation  and  application  were  also  experienced 
regarding  contract  end  item  (CEl)  specifications  and  contract  end  items  (CEI!s). 
Initial  thinking  was  obscure  regarding  whether  or  not  a  CEI  could  be  more  than 
one  single  Mblack  box"  and  the  permissibility  of  having  a  "CEI  within  a  CEI." 

The  selection  of  CEI's,  a  joint  determination  between  SPO  and  contractor, 
requires  careful  consideration. 

On  one  program,  CEI  specifications  were  defined  to  the  "black  box"  level 
to  assure  reprocurement  control  of  the  "black  boxes."  This  was  considered 
necessary  since  the  system  would  be  placed  in  operation  in  an  R&D  environ¬ 
ment  and  many  of  the  "black  boxes"  would  be  subject  to  removal,  replacement, 
and  improvement  modifications.  Although  the  basic  objective  was  achieved, 
the  Project  Office  was  faced  with  serious  problems  in  the  Acquisition  Phase. 

Initially,  there  were  115  separate  CEI*s,  primarily  classed  as  prime 
equipment  (CP)  with  only  a  few  classed  as  identification  items  (CD).  This 
meant  115  CEI  specifications  had  to  be  reviewed,  correlated,  updated, 
corrected,  and  approved.  Still  further,  the  Project  Office  was  committed  to 
Preliminary  Design  Reviews  (PDR's),  Critical  Design  Reviews  (CDR's),  and 
First  Article  Configuration  Inspections  (FACI!s)  for  each  prime  equipment  (CP) 
item.1  The  vast  amount  of  both  formal  and  informal  documents  created  a  huge 
paperwork  burden  for  the  Project  Off ice* s  limited  staff.  The  contractor 
experienced  a  considerable  burden  in  the  formulation  of  Category  I  test  plans 
and  procedures  for  each  of  the  CEI!s  and  the  Project  Office,  in  turn,  experi¬ 
enced  a  tremendous  problem  in  expediting  a  thorough  review  of  the  test  plans 
and  procedures. 

This  situation  was  alleviated  somewhat  by  identifying  a  "design  package" 
as  a  CEI.  Although  the  "design  package"  itself  consisted  of  other  separately 
packaged  CEI!s,  it  was  treated  as  a  single  entity  and  a  common  reference  for 
program  management.  A  CEI  specification  could  then  be  written  on  the  "design 
package . " 

The  relative  size  and  number  of  CEI*s  selected  for  engineering  management 
purposes  is  important  because  a  PDR,  CDR,  and  FACI  is  normally  required  for 
each  CEI.  A  small  number  of  CEITs  tends  to  make  the  management  and  conduct 
of  these  reviews  unnecessarily  complex  and  unwieldy  whereas  a  large  number 
of  CEITs  tends  to  create  confusion  and  redundancy  in  the  qualification  test 
program  (particularly  in  identifying  CEI  Category  II  test  requirements)  and 
increases  the  amount  of  work  associated  with  the  acceptance  process. 

Also,  it  is  well  to  point  out  that  the  relationship  between  CEI  specifica¬ 
tions  and  technical  manuals  to  be  delivered  has  at  times'  been  misinterpreted. 
Technical  manuals  are  prepared  in  accordance  with  the  Contract  Data  Requirements 
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List  (CDRL)  and/or  a  procuring  agency  approved  (updated)  technical  manual 
publications  plan  or  other  contractual  requirement.  Therefore,  it  is 
erroneous  to  assume  any  direct  correlation  between  technical  manuals  to  be 
delivered  and  CEI  specifications. 

An  identification  specification  (CD)  is  normally  prepared  in  accordance 
with  Exhibit  IV  of  AFSCM  375-i  for  less  complex  CEI's  that  are  used  to  support 
prime  equipment  CEITs.  Qualification  of  such  items,  considered  off-the-shelf, 
normally  consists  of  simple  inspection  and  demonstration.  However,  there  are 
times  when  an  off-the-shelf  item  can  perform  a  critical  function  and  be 
rather  complex  as  well  (e.g.,  magnetic  drum).  Consequently,  the  SPO  desires 
to  exercise  close  management  control  over  the  item.  Questions  were  initially 
raised  as  to  whether  an  identification  specification  was  the  only  type 
specification  that  could  be  written  for  off-the-shelf  items.  A  critical 
component  specification  (Exhibit  Vi)  can  be  prepared  even  though  the  item  is 
off-the-shelf.  By  so  doing,  close  management  control  can  be  obtained  because 
critical  component  specifications,  Part  II,  are  not  formally  approved  until 
the  CEI  in  which  the  component  is  installed  has  been  qualified. 

Design  and  development  for  a  given  CEI  begins  at  the  start  of  the  Acquisi¬ 
tion  Phase.  The  uniform  specification  program  is  based  on  the  concept  of 
prior  approval  of  specifications,  or  portions  thereof.  These  approved  por¬ 
tions  are  used  for  contract  control  of  design  and  development  in  addition  to 
being  delivered  as  a  product  of  the  program.  In  many  instances,  programs 
that  undergo  Contract  Definition  as  well  as  equipment  programs  are  not  always 
completely  defined  and  specified  prior  to  entering  the  Acquisition  Phase. 
Consequently,  there  are  times  when  Part  I  CEI  Specifications  may  or  may  not 
be  generated  or  if  generated,  may  not  be  approved  by  the  SPO. 

This  situation  results  in  either  the  Design  Requirements  Baseline  not 
being  established  or  being  established  but  not  approved  by  the  procuring 
agency  at  the  time  the  Acquisition  Phase  is  initiated.  In  such  instances, 
the  Design  Requirements  Baseline  must  be  established  as  soon  as  possible 
after  contract  award  (preferably  within  30  days).  In  any  event  formal 
acknowledgement  by  the  procuring  agency  of  Preliminary  Design  Review  comple¬ 
tion  should  not  be  given  until  establishment  of  the  approved  Design 
Requirements  Baseline . 
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SECTION  IV 


IDENTIFICATION  AND  ACCOUNTING 

AFSCM  375-1*  Exhibit  XI,  Paragraph  6.4.8,  requires  a  system  allocation 
document  be  prepared  for  system  programs  to  identify  the  aggregation  of  CEI 
equipments  and  aerospace  facilities  which  are  the  basis  for  system  design  and 
integration.  This  document,  which  is  additionally  used  by  Logistic  Command 
and  the  Using  Command  for  initial  planning  purposes,  is  comprised  of  two 
parts:  Part  I  and  Part  II.  It  identifies  the  system  configuration  at  each 

location  and  should  be  issued  30  days  after  formal  approval  of  the  Design 
Requirements  Baseline.  Experience  has  indicated  that  Part  II  of  this  docu¬ 
ment  must  contain  as  a  minimum  the  following  information: 

a.  CEI  Specification  Number. 

b.  Official  Equipment  Nomenclature. 

c.  CEI  Quantity. 

d.  Assembly  Top  Drawing  Number. 

Lastly,  questions  have  arisen  concerning  machine  programs  that  are 
available  to  industry  to  accomplish  configuration  accounting  when  automated 
data  processing  techniques  are  used.  For  information  and  guidance  purposes, 
it  is  well  to  point  out  that  Systems  Command  has  machine  programs  for  both 
the  IBM  Model  7080  and  Model  l4l0  Computers  and  that  all  Logistic  Command 
Air  Material  Areas  (AMA!s)  utilize  the  Model  7080  Computer.  If  approval  is 
received  from  the  procuring  agency,  these  machine  programs  to  accomplish 
configuration  accounting  are  available  to  industry  at  no  cost  from  Systems 
Command . 
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SECTION  V 


SUMMARY 


The  exhibits  contained  within  AFSCM  375-1;  dated  1  June  1964,  have  been 
extensively  applied  on  programs  assigned  to  ESD.  Experience  in  application 
has  revealed  instances  where  the  content  of  some  exhibits  has  required 
further  clarification.  Instances  where  interpretation  was  required  and  the 
workable  approaches  taken  which  were  considered  to  be  in  accordance  with 
the  intent  of  AFSCM  375-1  have  been  presented. 
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